The World Wide Web is the Internet's multimedia information retrieval system. In the Web environment, client machines communicate with Web servers using the Hypertext Transfer Protocol (HTTP). The Web servers provide users with access to files such as text, graphics, images, sound, video, etc., using a standard page description language known as Hypertext Markup Language (HTML). HTML provides basic document formatting and allows the developer to specify connections known as hyperlinks to other servers and files. In the Internet paradigm, a network path to a server is identified by a resource address called a Uniform Resource Locator (URL), and having a special syntax for defining a network connection. So-called Web browsers, for example, Netscape Navigator® (Netscape Navigator is a registered trademark of Netscape Communications Corporation) or Microsoft® Internet Explorer® (Microsoft and Internet Explorer are trademarks of Microsoft Corporation), which are application programs running on client computer systems, enable users to access information by specification of a link via the URL and to navigate between different HTML pages.
When the user of the Web browser selects a link, the client machine issues a request to a naming service to map a hostname (in the URL) to a particular network IP (Internet Protocol) address at which the server machine is located. The naming service returns an IP address that can respond to the request. Using the IP address, the Web browser establishes a connection to the server machine. If the server machine is available, it returns a Web page. To facilitate further navigation within the site, a Web page typically includes one or more hypertext references (“HREF”) known as “anchors” or “links”.
A “portal” is a Web application which arranges Web content into a portal page containing one or more “portlets”. A portlet is a Web component, managed by a portlet software container, which processes and generates dynamic Web content. This content, often called a fragment, can be aggregated by the portal with content from other portlets to form the portal page. The content generated by a portlet may vary from one user to another depending on the user configuration for the portlet. A portal can act as a gateway to one or more backend software applications and be provided on a separate portal server. The portal can be used to deliver customized application content, such as forums, search engines, email and other information, within a standard template and using a common user interface mechanism. Users can be offered a single, personalized view of all the backend applications with which they work and can obtain access to a plurality of those backend applications through a single security sign-on.
Web clients interact with portlets via a request/response paradigm implemented by the portal. Normally, users interact with content produced by portlets, for example by submitting forms or following links, resulting in portlet action requests being received by the portal which are forwarded by it to the portlets targeted by the user's interactions.
A portal server used to provide a client with access to backend applications is disclosed in United States Patent Application 2003/0167298, which is incorporated herein by reference. The portal server is positioned in a Demilitarized Zone (DMZ), between a pair of firewalls and implements authentication of the client and checking of access privileges of the client. If the client is authorized, it will be allowed to access the backend applications.
For further improved security, reverse proxy (also called IP-forwarding) topologies may be used. These use a reverse proxy server to represent a secure content server to outside clients. Outside clients are not allowed to access the content server; their requests are sent to the reverse proxy server instead, which then forwards the client requests to the content server. The content server, which may be a portal server, forwards the requests to the applications or application servers for processing. The reverse proxy server returns the completed request to the client whilst hiding the identity of the portal and application servers from the client. This prevents the outside clients from obtaining direct, unmonitored access to the real content server.
Reverse proxy servers require significant configuration in order to correctly serve applications. Moreover, the reverse proxy server may only be used for applications that have been developed with reverse proxying in mind, for example only for applications in which all links to files on a Web or portal server do not refer to the full host name. Further, using a reverse proxy server, it is not possible to change the configuration rules for a particular application—there is just one set of rules for all applications being reverse proxied by that server. Thus, by changing the rules for one application, the rules are changed for all applications. Additionally, reverse proxy servers cannot cope with the dynamic creation of Hypertext References (HREFs), for example by JavaScript™, or the parameterization of applets.
Thus there exists a need for a system which addresses the above mentioned problems.